Talk:Device file

Character Devices can be hard drives

FreeBSD has done away with Block Devices. Some more should be written about this in the Character Device section. —Preceding unsigned comment added by 192.156.198.15 (talk) 19:52, 5 January 2010 (UTC)

Clarification Needed

I'd like to suggest a re-write please. Perhaps based on sectioning information pertaining to Linux, Windows and BSD? For example, the Windows references are not clearly differentiated here. Notice that the third sentence follows a second sentence Windows reference. Does the word "They" in the third sentence refer to Windows systems, to Unix-Linux systems or to both? Maybe references to Windows differences should appear later in the article since the article points out that Windows borrowed the concepts from Unix? Clearly set off so that people can find the system they need described? — Preceding unsigned comment added by 70.253.70.197 (talk) 01:08, 3 April 2012 (UTC)

Remove the devfs section?

The tone of voice in the devfs section is opinionated. The section is also out of place in its context. It only serves to confuse the reader, especially when the table below it makes clear that devfs is deprecated now. Gwrede (talk) 09:50, 22 April 2009 (UTC)

Also, devfsd has its own page and this content should be merged with it and the devfs link should point to devfsd 91.58.158.56 (talk) 05:43, 8 May 2014 (UTC)

The devfs section isn't about Linux, it's about several operating systems, not all of which are even Unix-like. devfsd is about the Linux daemon, so it would be a serious mistake to move the generic multi-OS content of that section, which describes OSes that have no devfsd, to the Linux-specific devfsd page. Guy Harris (talk) 18:18, 28 April 2017 (UTC)

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Device name was merged into the Device files section of Device file system. --NerdBoy1392 18:18, 13 January 2009 (UTC)

---

There is another article by the name of Device name. (Which was made before this one) I was thinking about either merging it into this one (under the Device Files heading), or linking them with See Also links. Do you think the Device name article is significant enough to keep it separate, or should it be merged? I would probably completely replace the table under Device Files with the contents of Device name, as Device name has a lot more information. Otherwise the See Also links are trivial. --NerdBoy1392 <Talk|Contribs> 23:44, 19 October 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was page moved to device file.  Skomorokh  10:25, 27 December 2009 (UTC)

---

Device file system → device special file — This page mainly discusses the concept of a device special file, not the concept of a special file system that contains device special files It can continue to discuss the latter, e.g. in the devfs section, but the stuff above that section applies even to systems with device special files stored on the root file system. --Guy Harris (talk) 23:28, 16 December 2009 (UTC)

Note also that with "devtmpfs" (and with udev in general?), the file system in which the special files reside is just an instance of tmpfs, not a special devfs. Guy Harris (talk) 23:32, 16 December 2009 (UTC)

• I agree that main topic should be the Unix device file, because the file system is just the most recent implementation trend. And the article is correctly structured along these lines. But device file is much more common in books than device special file [1]. Pcap ping 00:35, 24 December 2009 (UTC)

OK, how about Device file system → device file, with device special file redirecting to device file? Guy Harris (talk) 20:05, 25 December 2009 (UTC)

That's what I was suggesting. Pcap ping 20:19, 25 December 2009 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Block devices dangerous????

Article states that block devices are dangerous, what part I missed? Linux uses block devices, for example, it's the first time that I read that... — Preceding unsigned comment added by Sebelk (talk • contribs) 16:34, 1 May 2013 (UTC)

Character Devices and Block Devices

In UNIX parlance, the distinction between character and block devices is that character devices expose the properties of the underlying hardware (e.g. they may disallow reads and writes if they are not aligned to the device block size), while block devices are buffered by the system. This is somewhat counter-intuitive as it leads to character devices necessitating that you read in whole blocks, while block devices will let you read a character at a time regardless of the block size.

The current description is, therefore, wrong, and so I’m going to update it. The reason for adding this comment on the Talk page is to dissuade people from changing it back without thinking. Ajhoughton (talk) 09:49, 24 April 2014 (UTC)

Hello there! Well, somehow you've got it quite wrong, let me quote one part of the content introduced by your edit:

Two standard types of device files exist; unfortunately their names are, for historical reasons, rather counter-intuitive, and explanations of the difference between the two are often incorrect as a result. [...] The character device for a hard disk, for example, will normally require that all reads and writes are aligned to block boundaries and most certainly will not let you read a single byte.

How can you have a character device for a HDD? Character and block devices got their names primarily by the amounts of data that's handled at a time by the underlying hardware device, and HDDs‍—‌as an example‍—‌internally operate with blocks of 512 bytes, or more recently with 4 KB sectors. At the same time, block devices provide permanent data storage and they're seekable, while character devices provide only "one time" actions and no data gets buffered. Thus, their names aren't counter-intuitive. See also this explanation, for example.

In a few words, your edit is quite misleading and I'll revert it, while adding one or two references to back the previosly present content. — Dsimic (talk | contribs) 01:21, 25 April 2014 (UTC)

No, I haven't got it wrong (it would be a surprise if I did, because I'm an expert in this area). The original article was wrong, which is why I edited it, and you're wrong too. That's why I wrote the explanation on the talk page, in the hope that someone might read it and not just immediately revert the change. It's very common to have a character device for a hard disk (for instance, on Mac OS X, the device "/dev/rdisk0" is the character device, while the device "/dev/disk0" is the block device). And you'll also note the comment about FreeBSD removing the disk block devices because they're dangerous, which means that the only disk devices on FreeBSD are character devices.

Nor is your claim that character devices provide only "one time" actions accurate. Some character devices are seekable (and SUSv4, which I referred to, is quite clear about that; IIRC it explicitly states that character devices other than terminal devices may be seekable). The only distinction is that block devices are buffered and don't expose hardware behaviour (like the underlying block size), whereas character devices are unbuffered and do expose hardware behaviour.

So, "in a few words", your revert is incorrect, your claims are incorrect, and I'm going to change it back again. Ajhoughton (talk) 20:25, 25 April 2014 (UTC)

The fact that BSDs treat them differently isn't the reason to present that as the only interpretation of character vs. block device meaning, while the old content of the article covers both interpretations. I'm not going to argue with you, and even less to go into edit warring. Feel free to revert and leave it for other editors to weigh in.

By the way, just have a look at this quote from the "block devices are bad" explanation:

The caching will reorder the sequence of write operations, depriving the application of the ability to know the exact disk contents at any one instant in time.

Isn't that what write barriers are there for? Sure, it's much simpler to ditch buffering than to implement write barriers. — Dsimic (talk | contribs) 02:38, 26 April 2014 (UTC)

It isn't that “BSDs treat them differently”, it’s that the name “character special file” comes from UNIX, so what is relevant here is what the Single UNIX Specification says, which unsurprisingly corresponds with the behaviour and documentation of System V and BSD UNIXen. Linux may very well be different — but Linux is not UNIX, and the distinction between character and block devices is not really present on other systems.

As for the comment from the FreeBSD documentation, you're right that write barriers improve matters for users of block devices, but they don't solve the problem of other software using character devices at the same time that you're using block devices to access the same underlying hardware. Ajhoughton (talk) 16:47, 29 April 2014 (UTC)

Well, Linux is different and it's here running on numerous computers and whatnot, so describing its behavior as well should be required in order for WP:NPOV to be maintained; the article isn't strictly only about device files in certified Unices. — Dsimic (talk | contribs) 17:45, 29 April 2014 (UTC)

The notion of "character special files"/"character devices" and "block special files"/"block devices" dates back at least to UNIX V6, and is implemented in many of the major Unix-like systems, including Linux and OS X and, I think, the current commercial UNIXes (Solaris, AIX, HP-UX), NetBSD, and OpenBSD. FreeBSD, however, has eliminated block devices.

Traditionally, file system I/O went through a buffer cache mechanism, and so did block special file I/O, so only devices capable of some approximation of random access had block special files (this included magnetic tapes, although the hardware for most tapes didn't support overwriting blocks, so, while you could do slow random-access reads, you had to do sequential writes).

"Character" special files just passed read, write and, in V7 and later, ioctl operations directly through to the driver. For disks, the seek offset had to be on a block boundary (looking at the source to physio(), if it wasn't on a block boundary, the lower 9 bits were treated as if they were 0), and the count would have to be an even number of words - as I remember, if it wasn't a multiple of the block size, 512, it would just not transfer the leftover bytes on a read, but I'm not sure what it'd do on a write. For tapes, the seek offset was ignored, and a block of the specified size would be read or written; I don't remember what happened on a read if the byte count was too small for the block on tape, but if it was too large, the read would return the actual block size on tape.

For non-disk and non-tape devices, there's typically only a character special file. Traditionally, disks and tapes had both types of files, and my OS X Mountain Lion machine has both block ("/dev/disk*") and character ("/dev/rdisk*") devices for disks, but the Linux kernel on my Ubuntu virtual machine appears to have only block special files for disks under /dev, and my FreeBSD 7.5 virtual machine has no block special files at all, only character special files, including for the disks. See section 9.4. "Block Devices (Are Gone)" of chapter 9 "Writing FreeBSD Device Drivers" of the FreeBSD Architecture Handbook.

Not all Unix-like systems have a traditional buffer cache, so the semantics of the disk block devices, if they exist, depend on the OS. For example, SunOS 4.x had a small buffer cache used for file system metadata that was not part of a file or directory's data, such as inodes and free block bitmaps, but the bulk of caching went through the page cache, which was a completely separate cache, indexed by file and offset within file, rather than by device and block number on the device as was done with the buffer cache. As I remember, the block special files used the buffer cache, not the page cache. On a system with only one buffer cache, I/O to a block special file would affect the same cache that the file system would use, but, on a system such as SunOS 4.x with two separate caches, I/O to a block special file wouldn't affect cached file data or directory data.

The notion of character special files is pretty much the same on all Unix-like systems, except for disks. Whether block devices even exist, whether disks offer block device interfaces, whether disks offer character device interfaces, and the way the block device interface to a disk works is, however, dependent on which system you're using. I think that, on the Unix-like systems where disks offer a character device interface, the behavior is the same - each read() or write() maps to a block-boundary multi-block read or write operation, perhaps with differences in what happens if the seek offset or byte count isn't a multiple of the sector size. Guy Harris (talk) 00:17, 22 October 2014 (UTC)

Thank you very much, Guy Harris, for providing such a detailed recap. I'm pretty much still at my old proposal, which would be to rewrite Device file § Character devices and Device file § Block devices sections so they describe all uses (or meanings) of these two device file classes. Even better would be to merge those two sections into a new section, Device file § Character and block devices, as they're pretty much interleaved. Any chances for you to do that rewrite, please? — Dsimic (talk | contribs) 20:34, 23 October 2014 (UTC)

Out of curiosity, are the "Unbalanced" templates in the character device and block device subsections there because of this discussion? Because they are what brought me to the talk page.

As to contribute something useful: character devices may indeed not allow single bytes to be read or written. If you get closer and closer to bare metal what you can and can not do is more and more dictaded by the capabilities of the hardware. Take for example sg, the Linux SCSI generic driver interace. The sg device files are character devices that provide access to SCSI devices including hard disks. You cannot read single bytes from/write single bytes to sg devices, only buffers of size of sizeof(sg_io_hdr_t). To quote from http://tldp.org/HOWTO/SCSI-Generic-HOWTO/intro.html: "This type of driver is sometimes termed as a "pass through". In the case of SCSI disks, the block subsystem which is normally used to mount and access a disk, is bypassed permitting low level operations such as formatting to be performed."

80.243.171.133 (talk) 16:14, 19 February 2015 (UTC)

Hello! Yes, those tags and this discussion go together. Thanks for your comment, but see, Ajhoughton says that "Linux isn't Unix" and that what Linux does isn't important. That would mean what half of the world does isn't important, but oh well. — Dsimic (talk | contribs) 09:17, 20 February 2015 (UTC)

While I disagree with that exact statement of Ajhoughton (especially since the section header is "Unix and Unix-like systems" which I feel covers Linux) I do in fact interpret the sg documentation as evidence that his original point

In UNIX parlance, the distinction between character and block devices is that character devices expose the properties of the underlying hardware (e.g. they may disallow reads and writes if they are not aligned to the device block size), while block devices are buffered by the system. This is somewhat counter-intuitive as it leads to character devices necessitating that you read in whole blocks, while block devices will let you read a character at a time regardless of the block size.

holds true for Linux as well as Unix. That of course is assuming that the sg driver is representative for character device drivers in Linux but I'd be very surprised if that wasn't the case. 80.243.171.133 (talk) 13:50, 21 February 2015 (UTC)

Ajhoughton's description would certainly apply universally if character device files/drivers were associated exclusively with storage devices such as hard disk drives. As we know, numerous character device drivers expose hardware devices that provide no storage at all – ordinary serial ports and keyboards come into mind as obvious examples. Do we need to read some kind of "whole blocks" when receiving data from a serial port? Certainly not. Thus, the sg driver doesn't represent all kinds of Linux kernel's character device drivers. — Dsimic (talk | contribs) 04:25, 22 February 2015 (UTC)

No, I did not say that “what Linux does isn’t important”. What I said was that the definition of character and block devices that we’re talking about here comes from UNIX and is documented in the Single Unix Specification. Linux does not always follow the specification, sometimes for good reasons, but in this case as far as I can tell Linux *does* follow the specification and you are simply confused about what “character device” versus “block device” means. That’s why when I changed the article I put a post on the Talk page explaining it. Nor, might I add, did I imply in the change to the article that you needed to read blocks of characters from a serial port character device. Ajhoughton (talk) 12:49, 27 July 2015 (UTC)

Clearly, Linux treats character and block devices differently; please compare chapters 3 and 16 from Linux Device Drivers, Third Edition for a clear overview of the differences. The chapter 16 also describes barriers on pages 485–486, which I've already mentioned above, and more information about barriers is available here. Here's a short quote from the chapter 16:

A block driver provides access to devices that transfer randomly accessible data in fixed-size blocks—disk drives, primarily. The Linux kernel sees block devices as being fundamentally different from char devices; as a result, block drivers have a distinct interface and their own particular challenges. [...] Efficient block drivers are critical for performance—and not just for explicit reads and writes in user applications.

Even Oracle Solaris says something similar about device drivers to what I've already noted in my earlier posts:

Device drivers are classified by how they handle I/O. [...] Block device drivers – for cases where handling I/O data as asynchronous chunks is appropriate. Typically, block drivers are used to manage devices with physically addressable storage media, such as disks. [...] Character device drivers – for devices that perform I/O on a continuous flow of bytes.

Oracle Solaris says this about device files:

Special files can be of type block or character. The type indicates which kind of device driver operates the device. Drivers can be implemented to operate on both types. For example, disk drivers export a character interface for use by the fsck(1) and mkfs(1) utilities, and a block interface for use by the file system.

Thus, I've restored the {{Unbalanced}} tags. The article needs to cover the nature and use of character and block devices in all Unix and Unix-like variants, not just by looking at them from the historical or "puritan" perspective, or by favoring exclusive use of character devices. The way it currently describes that character devices and "character-level" operations aren't connected is fine, though. Current article content also seems to be slightly misleading; let's have a look at how Oracle Solaris describes its simultaneous use of character and block devices:

Most block devices also have character interfaces. Disks have both block and character interfaces. [...] In this example, the block devices have blk in their names and the character devices have raw in their names. [...] The block devices access the disk using the system's normal buffering mechanism. The character devices provide for direct transmission between the disk and the user's read or write buffer.

As a result, it's somewhat misleading to state in Device file § Block devices that "there is a risk of data corruption" without explaining it in more detail. True, such inconsistency is a clear possibility in Linux when using raw devices that "clone" block devices into their character counterparts, as described in the raw man page, but Oracle Solaris seemingly mentions none of such limitations and that should be noted unless there's a better source that proves the opposite. — Dsimic (talk | contribs) 06:09, 24 August 2015 (UTC)

The problem here is still that you are confused, which is not surprising because the large number of bad or outright wrong explanations and the fact that the naming is a little counter-intuitive. The distinction is specifically that block devices are buffered (which has the effect that the article mentions, namely that you can read/write single bytes from a block device, but if your character device points at hardware that has a block size, you have to read/write whole blocks because character devices are unbuffered). It’s true that most systems have block devices for their disks — but a lot of them (Linux is an exception here) also have character devices for the same physical device, so that you can access the disk without going through the system’s buffers (in Linux you use O_DIRECT instead).

The Solaris docs to which you refer explain it exactly the way I have, which is probably not surprising because they will have been written by the people who worked on the Solaris kernel, who know their UNIX.

And, thankfully, Linux really does, by default, treat block and character devices exactly as I said; if you open a disk block device, it will, by default, be buffered. The only difference AFAICT is that Linux typically doesn’t also create character devices for disks and instead expects you to open the block device with the special O_DIRECT flag to get the behaviour you’d expect of a character device. It’s only Linux that uses O_DIRECT, though, and it doesn’t change the fact that without that flag, your accesses go through the buffer cache.

There is a slight irony here, in that Linux has opted, by default, to create only block devices for disks, while FreeBSD has opted instead to provide only character devices! FreeBSD's rationale for this change, as I understand it, is that it’s impossible to know when the buffer cache will be flushed, so using the block device is potentially dangerous. – Ajhoughton (talk) 15:51, 28 August 2015 (UTC)

Unfinished edit comment concerning MS-DOS

I love the MS-DOS arcana (that's my kind of encyclopedia), but it was too heavy for a lead beginning "in Unix-like operating systems", so I thinned and demoted, with some text overlap. — MaxEnt 17:35, 28 April 2017 (UTC)

Split device file system

I personally would split out the content concerning device file systems. Device file systems also have one foot firmly planted in managing hardware change events, itself a huge and contentious area (for which the footnote on MS-DOS would be rather spartan).

Virtual file systems is its own little area of computer science, quite apart from the original "everything is a file" abstraction that originally motivated device files. The content here on dfs is relatively weak and probably won't much improve while surrounded by so much nitty-gritty otherness. — MaxEnt 18:17, 28 April 2017 (UTC)

After adding yet more content to lead concerning dfs semantics, I went ahead and added a split tag. — MaxEnt 19:18, 28 April 2017 (UTC)

No discussion occurred, and somebody's removed the split tag. Either just do it or re-add the tag in an attempt to restart the discussion. Guy Harris (talk) 21:22, 16 January 2020 (UTC)

Windows 9x entry

I have some doubts about the Windows 9x entry. This has been added in an earlier revision of 2010-04-05 with the note I remember Windows having something like it too and the added code also contains an invisible comment as seen in the cdplayer.exe program.

Well, I checked the cdplayer.exe binary from Windows 98 SE for any occurrences of the substring device and only found the strings \Device\CdRom%d  <%c:> and GetDeviceCaps. The second one is irrelevant and the first one would suggest an NT namespace-like path (although I don't understand what the   <%c:> suffix has to do there).

Based on this I'd guess the device access in Windows 9x could be similar to Windows NT, but I cannot find any references to verify this. Also, the Windows 9x wouldn't probably have an NT namespace but something similar might probably have existed there.

Anyone knowledgeable enough with the Windows 9x family who could verify and/or fix this information?

-- JITR (talk) 23:35, 9 August 2017 (UTC)

node definition

Article starts talking about nodes without defining what they are. Should a separate article be written that defines node? Daniel.Cardenas (talk) 22:08, 6 October 2017 (UTC)

Concerning Translation

This article doesn't have a Chinese version linked to it, and when I try to create it with the name "设备文件" I find the name occupied. The Chinese article

These two articles, bearing the same name (though in different languages), share some of the contents, and there are also differences, a lot of them.

I also find that both of the two versions are linked with same pages (This article, in German is one of them), but the connection between the two of them seems to be lost.

How do you think I should deal with the problem? I have no trouble editing articles in either Chinese or English.

Linus Xu (talk) 01:33, 22 April 2018 (UTC)

If Google Translate is to be trusted, the Chinese page seems to be a page about device files in general, not just about the "device file system" in the sense of device file system (which currently links to the "devfs" section of device file, although there's a proposal to split that into a separate page).

My inclination would be to fix the first two paragraphs of the Chinese page to just speak of device files, rename it to the Chinese term corresponding to "device file", and then take anything from the English page that should also be in the Chinese page and add it to the Chinese page, and anything from the Chinese page that should also be in the English page and add it to the English page, to reduce the number of differences).

The German page you mentioned appears, if Google Translate is to be trusted, to be a page about the device file system, not about the notion of "special files" for devices. The German Wikipedia has a separate page about device files. Guy Harris (talk) 01:53, 22 April 2018 (UTC)

I'm currently on this. I'm editing the Chinese page so that it is more like "device file" than "device file system".

I will keep on translating. Nothing much for now. Thank you.

Linus Xu (talk) 11:36, 30 April 2018 (UTC)

MS-DOS borrowed the concept of special files from Unix but renamed them devices

This is wrong. It was inherited from CP/M to which it was inherited from TOPS-10.--Reciprocist (talk) 11:42, 7 March 2019 (UTC)